The invention relates to controlling the Quality of Service (QoS) in mobile communications systems having a packet data transmission capability.
Mobile communications system refers generally to any telecommunications system which enable a wireless communication when users are moving within the service area of the system. A typical mobile communications system is a Public Land Mobile Network (PLMN).
Often the mobile communications network is an access network providing a user with a wireless access to external networks, hosts, or services offered by specific service providers.
The general packet radio service GPRS is a new service in the GSM system (Global system for mobile communications), and is one of the objects of the standardization work of the GSM phase 2+ at the ETSI (European Telecommunications Standards Institute). The GPRS operational environment comprises one or more subnetwork service areas, which are interconnected by a GPRS backbone network. A subnetwork comprises a number of packet data service nodes SN, which in this application will be referred to as serving GPRS support nodes SGSN, each of which is connected to the GSM mobile communication network (typically to base station systems) in such a way that it can provide a packet service for mobile data terminals via several base stations, i.e. cells. The intermediate mobile communication network provides packet-switched data transmission between a support node and mobile data terminals. Different subnetworks are in turn connected to an external data network, e.g. to a public switched data network PSPDN, via GPRS gateway support nodes GGSN. The GPRS service thus allows to provide packet data transmission between mobile data terminals and external data networks when the GSM network functions as an access network.
In order to access the GPRS services, a MS shall first make its presence known to the network by performing a GPRS attach. This operation establishes a logical link between the MS and the SGSN, and makes the MS available for SMS over GPRS, paging via SGSN, and notification of incoming GPRS data. More particularly, when the MS attaches to the GPRS network, i.e. in a GPRS attach procedure, the SGSN creates a mobility management context (MM context). Also the authentication of the user is carried out by the SGSN in the GPRS attach procedure. In order to send and receive GPRS data, the MS shall activate the packet data address that it wants to use, by requesting a PDP activation procedure contexts (PDP, Packet Data Protocol). This operation makes the MS known in the corresponding GGSN, and interworking with external data networks can commence. More, particularly a PDP context is created in the MS and the GGSN and the SGSN. The PDP context defines different data transmission parameters, such as the PDP type (e.g. X.25 or IP), PDP address (e.g. X.121 address), quality of service QoS and NSAPI (Network Service Access Point Identifier). The MS activates the PDP context with a specific message, Activate PDP Context Request, in which it gives information on the TLLI, PDP type, PDP address, required QoS and NSAPI, and optionally the access point name APN.
The quality of service QoS defines how the packet data units (PDUs) are handled during the transmission through the GPRS network. For example, the quality of service levels (QoS) defined for the PDP addresses control the order of transmission, buffering (the PDU queues) and discarding of the PDUs in the SGSN and the GGSN, especially in the congestion situation. Therefore, different quality of service levels will present different end-to-end delays, bit rates and numbers of lost PDUs, for example, for the end users.
For each PDP Address a different quality of service (QoS) may be requested. For example, some PDP addresses may be associated with E-mail that can tolerate lengthy response times. Other applications cannot tolerate delay and demand a very high level of throughput, interactive applications being one example. These different requirements are reflected in the QoS. If a QoS requirement is beyond the capabilities of a PLMN, the PLMN negotiates the QoS as close as possible to the requested QoS. The MS either accepts the negotiated QoS, or deactivates the PDP context.
Current GPRS QoS profile contains five parameters: service precedence, delay class, reliability, and mean and peak bit rates. Service precedence defines some kind of priority for the packets belonging to a certain PDP context. Delay class defines mean and maximum delays for the transfer of each data packet belonging to that context. Reliability in turn specifies whether acknowledged or unacknowledged services will be used at LLC and RLC (Radio Link Control) layers. In addition, it specifies whether protected mode should be used in case of unacknowledged service, and whether the GPRS backbone should use TCP or UDP to transfer data packets belonging to the PDP context. Furthermore, these varying QoS parameters are mapped to four QoS levels available at LLC layer.
There are various problems, drawbacks, undefined issues and open questions involved with the quality of service in the GPRS.
Firstly, the above mentioned mapping of GPRS QoS parameters to four QoS levels available at LLC layer is not well defined either. In addition, relationships between delay class and service precedence are not defined in the standard.
Secondly, the scheduling and policing based on current QoS Profile is rather difficult to implement (and unspecified in the standard). For example, how the network elements can guarantee the delay requirements? It is too expensive to employ timers to guarantee the required delay requirements. Moreover, the delay requirements are end-to-end requirements: How this end-to-end delay information can be used by GPRS network elements is not obvious either. In practice they cannot because information about the delay occurred in the previous network element is not conveyed to the next element (i.e. GSN). Also policing the negotiated mean and peak bit rates is rather difficult and would consume a lot of time and processing power. In addition, if we wanted to make sure that a certain bit rate could always be provided, we would have to reserve fixed capacity for that. This would however lead to inefficient link capacity usage.
Interpretation of mean bit rate is questionable. GPRS network cannot guarantee a certain mean bit for a user if he or she is not transmitting at fixed speed, ie. at the mean bit rate. Otherwise, the user could have an one hour connection in which he or she has not transmitted any data for the first 55 minutes. The user cannot assume that he or she could transmit data at much higher speed during the last 5 minutes in order to meet the mean bit rate requirement. Instead, the mean bit rate can only be guaranteed for the rest of the connection, i.e. for the last 5 minutes.
The GPRS network is not capable of meeting various QoS requirements of Internet applications. The IP (Internet Protocol) traffic goes between the mobile host and the fixed host located in an external network, e.g. in the Internet. Different Internet applications require different kind of service, i.e. QoS, from the underlying network. Thus, when the mobile host is using GPRS to access the Internet, GPRS network should be capable of meeting various QoS requirements of Internet applications. There are actually at least two IP traffic types that should be taken into account: real-time and non-real-time traffic. One example of real-time traffic is voice transmission. Email and file transfer in turn are examples of non-real-time applications.
Currently, QoS parameters can only be associated with a certain PDP context (i.e. a certain IP address). Setting different QoS values for different applications that use the same IP address is not therefore possible. This is a very severe drawback of the current scheme. The current GPRS specifications also define only very static QoS behaviour: QoS negotiation can only be initiated by the MS when activating the PDP context. To summarize the main problems: GPRS QoS scheme is too static, i.e. QoS cannot be changed the MS or the GGSN after the QoS has been negotiated for the first time, and secondly, all applications that use the same IP address must also use the same QoS Profile, i.e. the QoS values. This is obviously not enough for supporting requirements of various Internet applications and traffic streams, such as voice transmission, real-time video, compressed video, email transfer, file transfer, and high priority control information exchange.
Internet includes at the moment two different QoS schemes: Integrated Services and Differentiated Services. Integrated Services consists of three traffic types: Guaranteed Service, Controlled Load Service, and Best-Effort Service. Guaranteed Service is very difficult to provide without introducing much overhead to the system. This overhead comes from the fact that end-to-end traffic flows should be established for different application connections. Therefore, this requires much database management, control information exchange, and traffic policing to be performed by the system. Controlled Load providers unloaded network behaviour even under congestion situations. Controlled Load can be implemented by priorities. Therefore implementing Controlled Load Service would probably be easier than Guaranteed Service, which needs strict guarantees on transmission delays etc. Best-Effort Service does not need any guarantees on the QoS, and is thus very easy to implement in any network.
Differentiated Services in the Internet are based on the idea that no data flows are needed, but instead every data packet carries QoS information itself. This allows very flexible and easy way to provide a certain QoS to applications. The drawback is that 100% guarantees of the capacity cannot be given because no fixed capacity is ever allocated to a certain application flow. However, this scheme is much more efficient from the capacity and system point of view than the Integrated Services scheme.
Similar problems as describe above may arise in any mobile communications network.
An object of the present invention to introduce a new improved Quality of Service (QoS) scheme which is less complicated than the prior art QoS schemes, in mobile communications systems having a packet data transmission capability.
Another object of the present invention is a new Quality of Service (QoS) scheme which provides support for Internet applications and their QoS requirements for mobile communications systems having a packet data transmission capability.
An aspect of the present invention is a data transmission method.
Other aspects of the invention are a mobile communications system, a network element and a mobile station.
A still further aspect of the invention is a packet data communications network.
In the present invention a dynamic packet-based quality of service (QoS) mechanism is provided within a xe2x80x9ctransmission tunnelxe2x80x9d defined by a more static packet data protocol context (PDP context). More particularly, each data packet is arranged to carry at least one QoS parameter, and the scheduling and the policing of the transmission of the data packets is made in packet by packet basis according to this QoS information in the packets, while, however, within the limits set by the PDP context. This concept enables to have any number of QoS profiles in use simultaneously, e.g. a dedicated QoS profile for each of several Internet user applications run in the mobile station for a IP address. Therefore, the present invention provides support for various Internet applications and their QoS requirements, which cannot be provided using the current QoS scheme of the GPRS, for example. Moreover, the QoS can be changed at any time after activation of the PDP context, since only the QoS information in the relevant data packets has to be changed. This overcomes the problems relating to the too static prior art QoS schemes. Further, the present invention introduces no or insignificant overhead into the mobile communications system as a whole.
In the preferred embodiment of the invention the QoS information associated with each data packet include at least a priority information and a traffic type information. The priority information has two or more values indicating the importance of the packet and thus also defines the order in which data packets should be handled or discarded in case of network congestion. The priority information may also define a Nominal Bit Rate as in SIMA approach. The traffic type indicates requirements for the transmission of the packet. At least two traffic types are typically defined: real-time and non-real-time traffic. However, more traffic types could be defined if needed. For example, for non-real-time traffic, the following subtypes could be used: control traffic, interactive traffic, attended bulk transfer, unattended data transfer, filler traffic, uncharacterized traffic, and best-effort traffic. The traffic type has an impact on retransmission strategies and data queueing in the network. For example, for real-time traffic, retransmissions of lost data packets are usually not needed, and it is often better to drop real-time data packets than to send them too late to the receiver.
In one embodiment of the invention also reliability is, instead of or in addition to being employed at PDP context level as is currently done in the prior art, directly associated with the QoS information in the data packet. The communications network, e.g at the LLC layer, is arranged to provide different connections each of which is associated with different reliability and QoS support. These connections may be provided in any one or several legs in the mobile communications network, e.g. at the radio interface and/or in a transmission link between two nodes in the network. One connection may be a connection oriented path having a higher reliability due to a retransmission protocol, for example, and another connection may be a connectionless path (e.g. using a User Datagram Protocol, UDP) having a lower reliability. Data packets are multiplexed over these connections based on the reliability and QoS information. The data packets requiring reliable transmission, should be sent over a reliable connection-oriented path. The data packets that do not require reliable connection-oriented path, should be sent over connectionless path. Both the connection-oriented and the connectionless path can be established to transfer packets of only one PDP tunnel or they can be used by several PDP tunnels. Furthermore, the establishment of different paths with different reliabilties can be dynamic or static (i.e. on demand or when the tunnel (PDP context) is created). This concept of the invention may applied in any packet data communications network, even in one not using any PDP context, such as TCP/IP, ATM, or X.25 networks.
As noted above, the PDP context defines a kind transmission tunnel with specific characteristics through a mobile communications network. As in the conventional networks, the parameters of the PDP context may include a PDP type (e.g. X.25 or IP), a PDP address (e.g. IP address), and a NSAPI (Network Service Point Identifier). The PDP context may or may not include also one or more QoS parameters. For example, mean and peak bit rate for the whole PDP context might or might not be used. The QoS of the PDP context may also include reliability. If both the PDP-level QoS Profile and the QoS in each data packet are to be used, the traffic policing may be based on the QoS values related to the PDP context, e.g. on mean and peak bit rate. Therefore, if the user is sending at too high speed, the priority of his or her data packets could be temporary decreased by the system. This guarantees that packets not conforming to the PDP level QoS contract are discarded first if needed. In addition, QoS information in data packets could be relevant only within the PDP context in question. This being the case, the QoS information in data packets is taken into account only in relation with the QoS Profile of the PDP context.
A further feature of the present invention may be a mapping of the QoS parameters used in the mobile-communication network to those used in a user application in said mobile packet data terminal or those used in said external communication system, and vice versa. The mapping is made for each packet entering or leaving the mobile communications system.
The QoS information in the data packets may be located in a packet header, in a lower layer protocol header, or as part of the data itself. The QoS controlling may also be based on the QoS information in QoS Profile, which is related to a certain PDP context, the priority and traffic type information included in the data packets, or both.
One embodiment of the invention involves also a charging of the users. Users can be charged, in addition to the normal PDP level attributes, by the priority and traffic type of data packets. This requires that the mobile communications network nodes, such as GSNs in the GPRS, collect information on the transferred data packets and their QoS and/or priority. On the other hand, invention also allows charging schemes that are using the normal PDP-level attributes, such as mean and peak bit rates of the PDP context, or a combination of these schemes.
In the preferred embodiment of the invention the mobile communications network is a packet radio network, such the General Packet Radio Service (GPRS) of GSM. The present invention may also be implemented in vendor-specific ways: data packets could include priority information although the current GPRS QoS Profile will still be used.
This invention will also apply to various future mobile networks, such as UMTS.